BIP47 v1 仕組み

BIP47 version 1 の仕組み

BIP ではないが、version 4 まである

Payment Code generation

Derivation Path は m/47'/ 0' /0'

A payment code contains the following elements:

Byte 0: version. required value: 0x01

Byte 1: features bit field. All bits must be zero except where specified elsewhere in this specification

Bit 0: Bitmessage notification

Bits 1-7: reserved

Byte 2: sign

compressed pubkey の偶奇を表すフラグ

Bytes 3 - 34: x value, must be a member of the secp256k1 group

m/47'/ 0' /0' の compressed pubkey の x 軸の値

Bytes 35 - 66: chain code

Bytes 67 - 79: reserved for future expansion, zero-filled unless otherwise noted

Alice to Bob

Payment code とは xpubkey である

HD wallet の原理で決定的に pubkey を導出することが可能

Alice は自身の private key と Bob の未使用 publickey から Shared Secret を生成する。

Bob の pubkey は、HD wallet と同じ仕組みで順番に導出される

未使用の定義は Alice と Bob 間での話である。

すなわち、Alice から Bob への一番目 transaction と Chrol から Bob への一番目の transaction に用いられる Bob のpublic key は同じ

Alice と Charol は private key が異なるからBob の同じ pubkey を使っても送金先 public key は異なるものになる

Bob は Alice の pubkey がわかっていれば、pubkey を導出することが可能

notification tx が必要

Alice の payment code の最初の子pubkey

https://gyazo.com/333c4533b3decd15399687d9eb513e3e

送金相手に自分の Payment Code を伝えるための transaction

送金のたびに生成される pubkey は、送金元と送金先の Payment code から導出される

したがって、受け取る側が、送る側の Payment Code を知らないと、入金を検知できない

notification address に対して送金する

notification address とは

Notification address: the P2PKH address associated with the 0th public key derived from a payment code

47'/0'/0'/0

最後は non hurdend

notification address は常に同じ？

送金側の pubkey には、notification tx の最初の input の pubkey を使う

Payment Code 自体は公開されていても問題ないものであるが、notification 内に生で書かれていると、Payment Code の持ち主の transaction であることが、Payment Code の持ち主を知っている人にはわかってしまう。

Payment Code は BIP32 の xpub key。鍵とchain code から構成される。

unmask するためには shared secret と outpoint がわかればよい

outpoint は既知

shared secret は ECDH で共有

Recovery

自分が受け取った tx については blockchain があれば復元可能

自分が送ったものは、相手の payment code の情報は blockchain にはないので復元できない

別の backup が必要

Downside

notification tx が必要

すぐに送金できない

blockスペースを消費する

コスト

notification address は ID と強く紐づいている。したがって notification address に送られた notification tx UTXO の取り扱いは難しい。

この UTXO と一緒に消費される UTXO は、同じ持ち主である可能性が高いと判断されてしまう

少なくともミキシングする必要がある、と提案者は考えている模様

Version 2 notification

1 は notification address への少額の送金が必要

2 では相手への送金は不要

change output を相手との 1of2 multisig address にロックする

受け取り側は自分への送金として検知できる